The modern communications era has brought about a tremendous expansion of wireline and wireless networks. Computer networks, television networks, and telephony networks are experiencing an unprecedented technological expansion, fueled by consumer demand. Wireless and mobile networking technologies have addressed related consumer demands, while providing more flexibility and immediacy of information transfer.
Current and future networking technologies continue to facilitate ease of information transfer and convenience to users. Due to the now ubiquitous nature of electronic communication devices, people of all ages and education levels are utilizing electronic devices to communicate with other individuals or contacts, receive services and/or share information, media and other content. One area in which there is a demand to increase ease of information transfer relates to services for providing applications to IVI systems of vehicles.
Currently, in the Terminal mode (a new smartphone to car interface developed by Car Connectivity Consortium) an IVI system may utilize Virtual Network Computing (VNC) for replicating a user interface of a mobile phone to a display provided by a vehicle to enable users to utilize the latest or current applications provided by the mobile phone with a vehicle's (for example, an old car) IVI system. When using the VNC connection, the frame rate of an application may be limited by the bandwidth of an underlying network connection between the mobile phone and the IVI system. As such, it may be difficult to support applications that may require high frame rates such as, for example, videos, games, and user interfaces.
One challenge in executing applications downloaded from a mobile device to an IVI system may be the lack of a device application programming interface (API) provided by the IVI system. A device API may refer to a JavaScript API provided to web (e.g., HTML) applications for accessing data from a mobile phone where the application may be running. An example of device APIs may be associated with contacts, calendar, GPS location, etc. Since new device APIs are currently being developed every year, an IVI system developed years ago (for example, in older vehicles) may not have all device APIs necessary to execute an application downloaded from a mobile phone, which tends to support the latest or most current APIs available. Even if a corresponding device API is available via an IVI system, the device API may not be particularly useful for the application. For example, a calendar device API provided by an IVI system may not include a most recent schedule of a user, even though a mobile phone of the user may have a calendar with the user's most recent schedule. However, the user may desire to be able to access his/her most recent schedule even if the application (e.g., a calendar application) is executed in the IVI system.
As a solution to this problem, a current mechanism for an IVI system to obtain device data from a mobile phone using a web interface may be dynamic translation of JavaScript code by replacing a caller of a device API into another code which may fetch necessary data from the mobile phone remotely. However, such a translation may take a long time depending on the amount of code being transmitted and translated. Another problem of current mechanisms for providing device data of a mobile device to an IVI system may involve lack of protection of a user's data. For example, sensitive data such as a user's calendar, contacts, and location may need to be protected to prevent malicious software running in an IVI system or other devices in the same network from accessing such data.
One solution to this issue may be to request a user to enter a password to access sensitive data, but this approach may be unrealistic for usage in vehicles. For example, when a vehicle is being driven by a user, it may be difficult and undesirable for the user to enter a password to access sensitive information. As such, a better mechanism for protecting sensitive data may be needed.
Another problem that may not be addressed by existing mechanisms of providing applications to IVI systems relates to driver distraction rules/regulations. Currently, existing mechanisms may not adequately provide information indicating whether an application being sent to an IVI system meets driver distraction rules/regulations and whether one or more functions of the application may be allowed while driving. As such, lack of such information related to driver distraction rules/regulations may require IVI systems to allow downloaded applications only when a vehicle is completely stopped. However, this may not be the most efficient use of the IVI system and a user may become dissatisfied at being unable to access desired applications while in transit.
In view of the foregoing drawbacks, it may be desirable to provide a more efficient and reliable mechanism of enabling provision of one or more applications to an in vehicle infotainment system.